1. Field of the Invention
The present invention relates generally to electronic mail (e-mail), facsimile (fax) conversion and fax to e-mail inter-conversion so as to eliminate the need for a Personal Computer and the like for receiving e-mail messages and particularly to automatic conversion of an e-mail message, destined for a particular address by an e-mail message sender, into a fax w document for forwarding thereof onto a fax machine for use by a fax machine user and for automatic conversion of a reply fax document, developed by the fax machine user, into an e-mail message for delivery thereof to the e-mail message sender.
2. Description of the Prior Art
Communications through systems capable of transferring electronic mail (e-mail) have become particularly ubiquitous in recent years. Somewhat prior to the wide scale use of e-mail, facsimile (fax) was used as a common method of communication albeit this type of communication is clearly only a written or printed form thereof. More recently, e-mail and fax methods of communication are both employed for transferring documents of various sizes and types, simple messages and, in the case of e-mail, even voice and audio information. Some background information regarding the infrastructure behind the use of e-mail and protocols for transferring the same is briefly provided.
In FIG. 1, a prior art e-mail exchange system 10 is shown to include an Network Access/Service Provider B 17, a data communications network 14 (such as an Advanced Research Projects Agency (ARPA)-Internet), an Network Access/Service Provider A 16, a Public Switched Telephone Network 13 and a user A 18. The network 14 is comprised of switching devices, computers and their interconnections. Such devices include routers, switches, servers and other types of data networking equipment for transferring data from one computer system or location to another. The ARPA-Internet is merely an example of such a network. The Network Access/Service Provider (NASP) B 16 is shown to include an e-mail server 20 representing the computer system or network of computer systems, which provide or add infrastructure to the NASP's overall e-mail exchange capability. Typically, the e-mail service provider 20 implements some or all of the various contemporary methods prescribed by conventions, adhered to by parties wishing to interchange data on the data communications network 14. Additionally, the e-mail services provider 20 may implement policies which limit or regulate the use of, or access to e-mail services within the Network Access/Service Provider A 16 network; perhaps for the purpose of deriving revenue or for security reasons as is deemed appropriate by the Network Access/Service Provider A 16 administrative authority.
Also shown in FIG. 1 is Network Access/Service Provider B 17 that is shown to include e-mail service provider 19. For the sake of the example, each of Network Access/Service Providers A 16 and B 17 may be considered to operate autonomously under separate administrative authorities, using a similar mechanism for the provisioning of e-mail services. In this example, only users within Network Access/Service Provider A 16 are discussed, operation would be similar for users of other network administrations (not shown).
The Network Access/Service Provider A 16 may serve to isolate the network user A 18 from the characteristics of the data communications network 14. The methods used for the communication and exchange of data between a network user A 18 and the Network Access/Service Provider A 16 may differ from methods used for the delivery and receipt of network user A 18 data to and from other parties reachable via data communications network 14.
The Network Access/Service Provider A 16 may act as a broker or forwarding agent in the delivery and receipt of a network user A 18 data. The Network Access/Service Provider A 16 may act as a forwarding agent for network user A 18 data after the network user A 18 is no longer reachable on the network (e.g. a temporary network user may have terminated it's connection). Similarly the Network Access/Service Provider A 16 may act as a proxy recipient for a network user's data until such a time as that network user A 18 becomes available for receipt of that data. This mode of operation is commonly referred to as “store and forward” operation.
In FIG. 1, the network user A 18 may be an individual accessing the data communications network 14 through Network Access/Service Provider A 16 subject to access policy imposed by the Network Access/Service Provider A 16 administrative authority. In such an example, the individual network user may be employing a modem or Integrated Subscriber Digital Network (ISDN) Terminal Adapter (TA) and is ‘calling’ into the Network Access/Service Provider over some Public Switched Telephone Network 13 (PSTN). The network user A 18 is capable of sending or receiving e-mail in accordance with the method prescribed by Network Access/Service Provider A 16 and is setup to use e-mail service provider 20 resources for the purpose of e-mail interchange. Such an arrangement is by some prior agreement between the network user A 18 and the Network Access/Service Provider A 16 whereby the network user A 18 has given consent that Network Access/Service Provider A 16 act as a proxy on behalf of network user A 18 for e-mail interchange.
By some convention, each Network Access/Service Provider, such as Network Access/Service Provider A 16, is assigned a unique designation, by the data communication network 14 administrative authority. In ARPA-Internet terminology this designation is referred to as the domain.
Individual network users such as network user A 18 are assigned a designation by the their Network Access/Service Provider administrative authority, such as the Network Access/Service Provider A 16 administrative authority, which is unique within that Network Access/Service Provider domain. In ARPA-Internet terminology this designation is often referred to as the user name or simply ‘user’.
The Network Access/Service Provider A 16 acts as an e-mail proxy agent for the set of network users, such as network user A 18, known to be administered by Network Access/Service Provider A 16. Each user, such as network user A 18, of data communications network 14 may be uniquely described by a domain designation qualified by a user designation. By convention, the given method for deriving unique e-mail designations for individuals such as network user A 18 is the merging of user with domain separated by the ‘@’ character (yielding something of the form user@domain). In the current embodiment of the ARPA-Internet, the globally unique designation thus formed, is described in reference [RFC819 Domain naming convention for Internet user applications. Z. Su, J. Postel. Aug. 1, 1982. RFC821 Simple Mail Transfer Protocol. J. Postel. Aug. 1, 1982.], which has been adopted for use as the ‘standard’ e-mail address designation method and is often referred to as a network user's e-mail address.
In FIG. 1 to send e-mail to another network user, network user A 18 composes an e-mail message 22 using some method, addresses the message to the desired destination addressee (for the sake of the ARPA-Internet example this is done by embedding the destination addressee inside the e-mail message itself) and saves the message for subsequent transmission to Network Access/Service Provide A 16. On establishing a connection to Network Access/Service Provider A 16, and having satisfied the Network Access/Service Provider administrative authority access policy requirements, network user A 18 ‘uploads’ or transfers pending e-mail message 22 from local storage to the e-mail service provider 20 in accordance with the previously agreed convention governing methods and protocols for e-mail transfer. On receipt of e-mail message 22 from network user A 18, e-mail service provider 20 typically stores the e-mail for subsequent delivery (shown as e-mail message 23 in FIG. 1) and sends a delivery acknowledgement 27 to network user A 18. On receipt of the acknowledgement from e-mail service provider 20, network user A 18 typically removes e-mail message 22, previously stored for transmission, from it's local storage facility and considers e-mail message 22 to be delivered.
The e-mail service provider 20 may receive requests to deliver e-mail from network users both within it's domain of authority and from outside it's domain of authority. Similarly, the e-mail service provider 20 may receive requests to deliver e-mail to network users both within it's domain of authority and to users outside it's domain of authority. For each e-mail message to be delivered, the e-mail service provider 20 attempts to ‘deliver’ the message to the e-mail service w provider specified by the destination addressee domain. In cases where the destination domain specified is other than the Network Access/Service Provider A 16 domain, the delivery attempt will result in the message being sent via the data communications network 14. Delivery attempts to destination addressee within the Network Access/Service Provider A 16 remain local to the e-mail service provider 20 network.
In FIG. 1 the destination addressee specified is a network user (not shown) in the administrative domain of Network Access/Service Provider B 17. In order to deliver e-mail message 23, e-mail service provider 20 contacts it's peer, e-mail service provider 19 in Network Access/Service Provider B 17 via data communications network 14 and ‘uploads’ or transfers pending e-mail message 23 to the e-mail service provider in that domain. On receipt of e-mail message 23 from e-mail service provider 20, the peer e-mail service provider 19 in Network Access/Service Provider B will typically store the e-mail for subsequent delivery (shown as e-mail message 24) and acknowledges receipt of e-mail message 23 to e-mail service provider 20. On receipt of the acknowledgement from the peer e-mail service provider 19, e-mail service provider 20 typically removes e-mail message 23, previously stored for transmission, from its local storage facility and considers e-mail message 23 to be delivered.
FIG. 2 shows the path of an e-mail message 34 originating from a network user (not shown) of Network Access/Service Provider B 17 which has the destination address set to the designation of network user A 18. The e-mail message 34 may perhaps have arrived at the e-mail service provider 19 in a manner similar to that of the case exemplified in FIG. 1 previously. On detection of pending e-mail message 34 for delivery to another administrative domain, e-mail service provider 19 contacts it's peer, e-mail service provider 20 in Network Access/Service Provider A 16 via data communications network 14 and ‘uploads’ or transfers pending e-mail message 34 to the e-mail service provider in that domain. On receipt of e-mail message 34 from e-mail service provider 19, the peer e-mail service provider 20 in Network Access/Service Provider A 16 will typically store the e-mail for subsequent delivery (shown as e-mail message 33) and acknowledges receipt of e-mail message 34 to e-mail service provider 19. On receipt of the acknowledgement from the peer e-mail service provider 20, e-mail service provider 19 typically removes e-mail message 34, previously stored for transmission, from its local storage facility and considers e-mail message 34 to be delivered.
The e-mail message destined for network user A 18 is saved by e-mail service provider 20 until such a time as network user A 18 is detected as reachable and available to receive e-mail. Various methods and protocols may be employed to trigger the transfer of e-mail from e-mail service provider 20 to network users such as network user A 18, commonly used approaches require users such as network user A 18 to poll or solicit for available e-mail 36 from e-mail service provider 20.
The methods and protocols used for the transfer of e-mail between network user A 18 and e-mail service provider 20 and for the interpretation and identification of source and destination e-mail addresses are governed by Network Access/Service Provider A 16 administrative authority policy.
Methods and protocols used for the transfer of e-mail between e-mail service providers in different administrative domains are defined in a body of evolutionary specifications called Request For Comments (RFC) and form the basis of the ARPA-Internet related recommendations for protocols and methods. Those methods include but are not limited to protocols and facilities such as the Post Office Protocol (POP) [RFC1725 Post Office Protocol—Version 3. J. Myers, M. Rose. November 1994.], Internet Message Access Protocol (IMAP), [RFC1730 Internet Message Access Protocol—Version 4. M. Crispin. December 1994.] and Simple Message Transfer Protocol (SMTP) RFC821 Simple Mail Transfer Protocol. J. Postel. Aug. 1, 1982 widely in use in contemporary ARPA-Internet e-mail exchange environments.
FIG. 3 shows a typical embodiment of the prior art; a NASP network environment 50 w including a connection to an external data communications network 52, a NASP A 53, a PSTN 58, and a plurality 1-U of network users 60, each capable of initiating and tearing down, on demand, a data connection to NASP A 53 over the PSTN 58. The NASP A 53 is shown to include an e-mail service provider 64, mass storage capability 62 and a plurality 1-N of interconnections to the PSTN network 58 each terminating at some PSTN interface equipment 59 such as modems or ISDN terminal adapters (TA). The e-mail service provider 64 and mass storage capability 62 may be in the form of a computer system or network of computer systems running some dedicated applications software and providing mass storage capability. The NASP A 53 is connected to the external data network 52 for the exchange of data, including e-mail data, with other foreign network users and resources (not shown). The actual methods and protocols for the exchange of data over the external data network are as defined by the regulatory and administrative authorities of data communications network 52.
In operation, the e-mail service provider 64 typically executes some purpose built or dedicated e-mail interchange software (e.g. SMTP) for the interchange of e-mail messages. In a real-world environment, the NASP administrative authority would perhaps implement some access control and network user billing policies and infrastructure to support those policies. In such an embodiment, the administrative authority through some proprietary accounting system maintained by the administrative authority would likely know each temporary network user 60. Resource usage within the NASP would perhaps be monitored on a per temporary network user 60 ‘account’ basis and per user billing information derived accordingly.
Typically, subject to NASP administrative authority policy, each temporary network user 60 would be allocated some mass storage resource budget or quota which would serve to regulate or provide an upper limit to the amount of data maintained by the NASP on behalf of any given user.
The e-mail service provider 64 may assign a portion of the allotted mass storage of each temporary user 60, within the NASP A 53 administrative domain, for use as a users' receive mailbox. The e-mail service provider 64, stores a message destined for a temporary network user 60 in that user's assigned mailbox, until being picked up by the temporary network user 60 allocated that mailbox.
As described previously, the destination addressee for an e-mail address is associated with the e-mail message by some embodiment specific means. In the ARPA-Internet case, the evolutionary Multimedia Internet Mail Extensions (MIME) [RFC2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. N. Freed & N. Borenstein. November 1996; RFC2046 Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. N. Freed & N. Borenstein. November 1996; RFC2047 MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text. K. Moore. November 1996; RFC2048 Multipurpose Internet Mail Extensions (MIME) Part Four Registration Procedures. N. Freed, J. Kiensin & J. Postel. November 1996; RFC2049 Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples. N. Freed & N. Borenstein. November 1996.] specifications together with other related evolutionary definitions, e.g. “RFC822—Standard for the format of ARPA Internet text messages”. D. Crocker. Aug. 13, 1982, describe methods for the encoding and interpretation of certain data items within e-mail messages for use by e-mail delivery infrastructure. Such data items identify the source and destination e-mail addresses, describe the content of the message, identify possible multiple recipients, describe cryptographic and other security measures which may be in effect together with other standard, as per the evolutionary body of RFCs, data items of significance to various members of the network community.
Typically, a useful embodiment of the current invention employs methods for confirming the transfer of an e-mail message at any transit point between peer e-mail service providers and e-mail service provider to network user e-mail exchanges. Referring to FIG. 3 if the e-mail service provider 64 receives a request to deliver an e-mail message to an unknown or non-existent user in the NASP domain, the e-mail service provider 64 creates and sends ‘reply’ e-mail to the originator of the message, declaring a delivery failure. In forming the deliver failure notification, the originator of the e-mail is one of the key data items typically associated with the e-mail message and is determined by the e-mail service provider 64 using contemporary methods, e.g. refer to references: [RFC822, RFC2045-2049, as recited above] If the user is known within the NASP administrative domain, and subject to NASP administrative authority policy, the received e-mail will be accepted by the e-mail service provider and saved within the mass storage quota assignment for the destination addressee (i.e. in the user mailbox) for later retrieval by the corresponding temporary network user 60 assigned that destination addressee name.
Referring still to FIG. 3, in operation, in one embodiment of the present invention, a temporary network user 60 initiates a call to a prearranged phone number within the NASP A 53. The phone call is switched via the Public Switched Telephone Network (PSTN) 58 and presented to available PSTN interface equipment 59 within the NASP A 53. On detection of an incoming call, the PSTN interface equipment 59 answers the call and attempts to identify the caller using some prearranged method.
Once the temporary network user 60 has satisfied the identification requirements imposed by the NASP A 53 administrative authority, the temporary network user 60 typically polls or solicits for any pending e-mail in the assigned name of temporary network user 60. This solicitation is performed using some prearranged protocol and is initiated at the temporary network user 60 behest. Pending e-mail is ‘downloaded’ from the e-mail service provider 64 mass storage capability 62 and transferred via the PSTN to the temporary network user 60 as previously described in FIG. 2. In the current embodiment, temporary network user 60 client software such as the popular Microsoft Windows 98 (and later revisions) operating system implement support for e-mail transfer using methods such as the Post Office Protocol (POP) [RFC1725, as cited above] and Internet Message Access protocol (IMAP), [RFC1730 as cited above.]
The operation of the e-mail service provider 64 together with the mass storage capability 62 may be considered to be analogous to the operation of the U.S. Post Office in that as e-mail messages arrive, they are classified by the service provider 64 based on the destination addressee and the sorted result delivered to mailboxes particular to the destination addressee, analogous to residential mail boxes, where the messages wait to be picked up by the owners of each mail box.
Various methods and protocols are employed to cater for the environmental factors which influence behavior of communications networks; factors such as data loss due to noise (say due to electromagnetic interference) and system failure have a significant impact on data communications reliability. In data communications networks, such as the ARPA-Internet, the protocols, methods and strategies employed to deal with these factors are specified in various published RFCs and other proprietary texts.
In a typical embodiment of the current invention, protocols and device control components are employed, each component being responsible for some particular aspect of a service or function within the system. The components are assembled in an ordered fashion where to perform an overall system function (e.g. to send an e-mail message), each of the components is executed in turn. When viewed as an ordered execution sequence, the component interaction forms a hierarchy. The hierarchy or ‘layering’ of protocols related to typical contemporary ARPA-Internet data communications as described in relevant RFCs.
In the current ARPA-Internet implementation, and in view of the reliable transport facilitated by the Transport Control Protocol [RFC793 Transmission Control Protocol. J. Postel. Sep. 1, 1981. TCP is commonly used as the transport protocol for the interchange of e-mail messages between computer systems throughout the ARPA-Internet network.
FIG. 4 shows a representations of the layering of applications level 80 components such as POP over the host (transport) level 81, which in turn is layered above the network level 82, which ultimately is layered above the link level 83. In brief, a message originating in the applications level 80, traverses through the lower levels until ultimately being passed by the link level 83 to a device level (not shown).
FIG. 5 shows a possible contemporary practical implementation of a typical temporary network user provisioning 97 where the user equipment provisioning consists of a network user Personal Computer (PC) 89 on which is installed necessary software components to support the layered functions of e-mail reader 91, POP Client 92, TCP Services 93, IPV4 Services 94, PPP Services 95, Device Control 96 and is further provisioned with a Modem or ISDN terminal adapter 90 which in turn connects to a PSTN 88.
This serves to complete a brief background of the way in which e-mail messages are transferred from one computer equipment to another using a network, such as the ARPA-Internet. The reader's attention is now drawn to some of the problems associated with such usage.
A user of e-mail must have the infrastructure, such as a PC, to support the various functions discussed with reference to FIG. 5. A user located in a remote area, such as a small shopkeeper operating in a rural area, may not have access to or desire to accrue the expense associated with investing in such an infrastructure. Secondly, even if such an infrastructure were in place, an e-mail user would have to poll his e-mail account on his pre-assigned server (through his/her NASP) in order to check for messages. This can be an expensive proposition in light of having to pay telephone toll charges for making the call and/or connection time when checking for e-mail messages. Often, the checking of e-mail yields negative results in that more often than not, there simply are no new messages. But without checking for messages and thus accruing expensive telephone calls, the user is not going to be sure of the existence of potentially urgent or important messages. The latter problem regarding telephone expenses is particularly prevalent in some countries abroad that charge substantial fees even for local telephone calls.
In summary, e-mail users generally go through a NASP for establishing an e-mail connection and for accessing the ARPA-Internet. Certain group of e-mail users, most commonly corporations, firms and other types of organizations, typically have dedicated e-mail servers positioned locally within their organization for continuous access to the ARPA-Internet and therefore e-mail. These types of users only require their NASP to provide a “pipe” to the ARPA-Internet and potentially require domain name services. Other users of e-mail require their e-mail messages to be stored by their NASP and forwarded to them upon demand. This is due to these users' not-so-permanent connections to the ARPA-Internet, yet a desire to be “virtually permanent” at least relative to the delivery of e-mail messages.
One of the limitations with the latter users' access to e-mail is that they must poll their mail boxes (provided to them by their NASP) frequently in order to determine whether or not they have any e-mail messages. The increased reliance on e-mail has resulted in a high frequency of polling for messages, which can obviously be cumbersome and wasteful in time.
Additionally, another type of users of e-mail have a desire to have access to e-mail and yet do without the infrastructure, i.e. PC, modem and other types of equipment, for accomplishing the same. Examples of such type of users are shopkeepers located in remote areas of the world, perhaps stockbrokers and others. Shopkeepers or owners of small businesses who wishes to accept e-mail orders (which has become quite common recently), may not wish to invest in dedicated hardware equipment for doing the same and would therefore be denied access to e-mail. Therefore, the problem that this group of users encounters is the acceptance of Web-based ordering with an e-mail presence and a “virtual permanent” connection for accomplishing the same without the need for any dedicated equipment other than a fax machine.
Thus, the need arises for a system and method for accepting and sending e-mail messages without the use of equipment that is in communications with the ARPA-Internet so as to reduce operating costs for small enterprises and individual ARPA-Internet users while reducing latency associated with dialing up for checking for messages.